REMARKS 

I- Introduction 

In response to the Office Action dated August 28, 2001, please consider the following 
remarks. Re-examination and re-consideration of the application, as amended, is requested. 

IL Allowed Claims 

In paragraph (2), the Office Action indicates claims 2-8 and 28 are allowable. The 
Applicants acknowledge this statement of aUowabiHty, but traverse the rejection of the rejected 
claims, 

III. The Cited References and the Subject Invention 

A. The Kalra Reference 

U.S. Patent No. 5,953,506, issued September 19, 1999 to Kaka et al. discloses an apparatus 
and method for encoding, storing, transmitting and decoding multimedia information in the form of 
scalable, streamed digital data. The data streams of interest include a base data stream (of base 
informational content or resolution) and one or more additive data streams (having additional data 
content, presumably of higher resolution). As the Office Action acknowledges, the data streams are 
not provided according to different protocols. Rather, they represent additive data similar data of 
different resolutions and are provided under a single protocol. 

B. The Beckerman Reference 

U.S. Patent No. 6,029,200, issued February 22, 2000 to Beckerman et al. discloses an 
automatic protocol roUover in streaming multimedia data delivery system. Unlike the Kaka 
reference, the Beckman reference at least addresses the problem of handling different protocols. 
However, the Beckerman reference handles protocol differences in an entirely different way than the 
AppUcants' invention. The Beckerman reference teaches the use of a reference file. The reference 
file includes resource specifiers for attempting communication according to different protocols. The 
reference file also includes information describing which protocols should be attempted first when 
attempting communications. 
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IV, Office Action Prior Art Rejections 

In paragraph (4), the Office Action rejected claims 1; 10-21, 23-27, and 29-32 under 35 
U.S.C. § 103 unpatentable over Kalra et al., U.S. Patent 5,953,506 (Kalra) in view of Beckerman, U.S. 
Patent No. 6,029,200 (Beckerman). Applicants respectfully traverse these rejections. 

With Respect to Claims 1. 19. and 29 : Kalra teaches sequentially appending additive data 
streams of the same protocol into a single segment. It does not teach sequentially appending 
streams of data according to each subsequent version of a streaming protocol into a single segment. 
Beckerman teaches a system that addresses the issue of handling different data protocols, but the 
disclosed system handles different protocols in an entirely different way than the Applicants' 
invention. Beckerman essentially adopts a "brute force" solution in wliich die protocol information 
is described in a reference file, and communication is attempted using each of the protocols in the 
reference file, in an order that is also described.in-the reference file. 

Kaka does not address the issue of different protocols at aU. All it teaches is transmitting a 
data stream with additive components of increasing resolution. Nor does it provide any incentive, 
any teaching, or any reason whatsoever to do so. The Office Action indicates that one skilled in the 
art would be motivated to incorporate streaming multimedia using different protocols to "utili2e the 
combination of streams for encoding, storing, transmitting, and decoding a multimedia system." 
However, the Kaha reference already uses a combination of streams for encoding, storing, 
transmitting, and decoding a multimedia system." It however, does not permit those data streams to 
have different protocols. And why should it? The focus of the Kalra reference is transmitting data 
of differing resolution to computer systems that can utili2e the additional resolution. Nowhere does 
the Kalra reference even remotely suggest that the disclosed method be used with different 
protocols. In fact, the protocol used in the preferred embodiment of the Kaka reference (MPEG 
encoding) is quite detailed in appkcation and utterly incompatible with non MPEG-compliant 
coding techniques. 

The Office Action also indicates that one skilled in the art would be motivated to modifj^ 
Kaka to handle different protocols for each stream because doing so would "improve data delivery 
on the multimedia network." Of course, the same "motivation" could be used to reject any 
improvement on any data transmission system. The issue is whether one skilled in the art would do 
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so using the technique described in the Applicants' claim 1, and this is certainly not the case. Insofar 
as dealing with protocols and not additive data, the Kalra and Beckerman references would teach 
one of ordinary skill in the art to handle different protocols the way the Beckerman reference does it 
... by use of a reference file having protocol information. For all these reasons, the AppUcants 
respectfully traverse the rejection of claim 1. 

With Respect to Claims 13. 24. and 30 : According to the Office Action, claims 13, 24, and 
30 include limitations similar to those of claim 1, except the step of testing, prior to receiving each 
additional stream of data, whether an end of the data segment has been detected, and if so, 
terminating reception of the data segment prior to receiving the additional stream of data according 
to the selected version. According to the office action, these limitations are disclosed in Beckerman 
as follows: 

In accordance with the invention, a hyperlink to multimedia content is actually an indirect link to a reference file. The 
reference file contains a plurality of different resource specifiers and a preferred order for attempting communications using 
the resource specifiers. Each resource specifier designates a transport protocol. 

FIG. 4 shows an example reference file 40. Its first line consists simply of the string "[reference]". Following this line are 
one or a plurality of additional lines, each containing a different resource specifier in standard network URL format The 
order of the resource specifiers establishes a preferred order for attempting communications with the resources specified by 
the resource specifiers. Each resource specifier is preceded by an identifier of the form "Ref#=URI,". The # part of the 
identifier indicates the preferred order for attempting communications. For example, Refl is before Ref2. Alternatively, the 
reference file can specify the preferred order by referencing another file that in turn contains a specification of resources in 
their preferred order. 

FIG. 6 shows an example of a reference file 70 containing a resource specifier with an "mms" protocol specifier as well as 
other resource specifiers. Suppose in conjunction with this example that the client has configured player 38 to allow only 
the HTTP protocol The first resource specifier in reference file 70 contains the "mms" protocol specifier, meaning that the 
client should try the UDP/IP, TCP/IP, and HTTP transport protocols, in that order. However, the mms protocol specifier 
does not override the user s settings, so HTTP is the only protocol attempted in response to the first resource specifiers. If 
this is not successful, the player responds to the next line which has a protocol specifier equal to "mmu". This indicates that 
the player is to try a UDP/IP connection regardless of the user preferences. Thus, the server can override the client 
settings, and sometimes force a connection even when the cUent settings would have prevented such a connection. 

In accordance with other aspects of the invention, a step is performed of retrieving a resource reference or reference file 
from a network source. This is preferably performed in response to a user selection, such as activation of a hyperlink that 
specifies the reference file as its target. The reference file contains a plurality of different resource specifiers and a 
designated order for attempting conununications using the resource specifiers. Each resource specifier designates a 
streaming data resource and an associated transport protocol. 

A further step in accordance with the invention comprises repeatedly attempting to establish a streaming data connection 
using the different resource specifiers, in the designated order, until a streaming data connection is successfully established. 
Each attempt with a different resource specifier uses the streaming data resource and the associated transport protocol 
designated by that different resource specifier. Once a connection has been successfully made, the player renders the 
received multimedia content in video and/ or audio format. 

If a particular resource specifier has a protocol specifier having a predefined value ("mms"), a step is performed of 
repeatedly attempting to estabUsh a streaming data connection with the streaming data source specified by said particular 
resource specifier until a streaming data connection is successfully established. Each attempt uses a different transport 
protocol in a predetermined order or sequence that is not configurable by the user. 
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The Applicants fail to see where the limitations of claim 13, 24, and 30 are disclosed in the 
foregoing passages. The Beckerman reference does not disclose testing to determine whether an 
end of a data segment has been detected, and if so terminating the reception of the data segment 
prior to receiving an additional stream of data. 

V. Dependent Claims 

Dependent claims 10, 11, 12, 14-18, 20-21, 23, 25-27, and 31-32 incorporate the limitations 
of their related independent claims, and are therefore patentable on this basis. In addition, these 
claims recite novel elements even more remote from the cited references. 

For example, Claim 10 recites that no additional tags are embedded in the data segment 
between the begin and end tags. The Office Action indicates that this is a matter of design choice, 
but the Applicants disagree. It would seem that the simplest way to implement a plurality of data 
segments, each having a different protocol, would be to use tags between each data segment to 
identify the protocol of the data that follows. 

Further, with respect to claim 11, the Office Action indicates that the Kalra-Beckerman 
references disclose determining if the data segment is stored in a current context, and if so, 
transmitting an alias tag in Ueu of the data segment, and if not, storing the data segment in the 
current context. These limitations are said to be disclosed in the following passage: 



The *.asx files are referred to generically herein as reference files. Such files are made available from network 
servers 14, and are preferably integrated into the WWW. Hyperlinks to the reference files are placed in Web 
documents, and a user retrieves a particular reference file by clicking on its hyperlink. In response, the user's 
Internet browser retrieves the reference file from the server or other network source and opens it with player 38. 
Player 38, in turn, uses the reference file to establish a streaming data connection which the player then renders. 

FIG. 4 shows an example reference file 40. Its first line consists simply of the string "[reference]". 
Following this line are one or a plurality of additional lines, each containing a different resource 
specifier in standard network URL format. The order of the resource specifiers establishes a preferred 
order for attempting communications with the resotirces specified by the resource specifiers. Each 
resource specifier is preceded by an identifier of the form "Ref#=URI,". The # part of the identifier 
indicates the preferred order for attempting communications. For example, Refl is before Ref2. 
Alternatively, the reference file can specify the preferred order by referencing another file that in turn 
contains a specification of resources in their preferred order. 
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The AppUcants do notb^^ttl^M'how the foregoing passage discloses the elements of 
AppHcants claim 11. Accordingly, the AppUcants traverse this rejection. 




VI. Conclusion 

In view of the above, it is submitted that this application is now in good order for allowance 
and such allowance is respectively solicited. Should the Examiner believe minor matters still remain 
that can be resolved in a telephone interview, the Examiner is urged to call Applicants' undersigned 
attorney. 



Howard Hughes Center 
6701 Center Drive West, Suite 1050 
Los Angeles, Cahfomia 90045 
(310) 641-8797 



By their attorneys, 



Mark E. Davis et al. 



Respectfully submitted. 



GATES & COOPER LLP 




Date: 





Reg. No.: 39,641 



VGC/sjm 
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